@Matt-Gessner we don't have short term plans to work on Cloud Compile, but we do have two alternate ways to compile C programs for your Omega: Compiling directly on the Omega Cross compiling on your computer and transferring the binary to the Omega Setting up the Build System Cross Compiling Programs Cross Compiling Programs that use External Libraries So for the short-term, I would recommend buying a bigger SD card and exploring cross compilation

Update two weeks later: Still queued. Is cloud compile no longer available? Onion Blog: Cloud compile Post about problems with Cloud Compile in Feb 2017

Just as an aside, the whole reason for starting this whole discussion, I'm still showed "queued" on cloud compile. What's that now, 3 weeks or so?........ Cloud compile is crap slow. Just a little.

If you want to build C (etc) programs from source, you need a mipsel_24kc_gcc-5.4.0_musl-1.1.15 or similar toolchain - mipsel_24kc being the machine specification and musl being the C library used by LEDE. One way to get one is to build a suitable LEDE image from source, though there may be places you can download it. A crude approach is then to use command line environment variable overrides, ie STAGING_DIR=$(ABSOLUTE_LEDE_PATH)/staging_dir/ GCC=$(ABSOLUTE_LEDE_PATH)/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.15/bin/mipsel-openwrt-linux-musl-gcc make whatever But this is crude because is assumes that your build system is looking for a GCC variable, if it is looking for a CC it will break and build for the development machine instead. And anything that uses autoconf or pkgconfig, etc will be broken. The upstream cross-compilation instructions are at https://lede-project.org/docs/guide-developer/compile_packages_for_lede_with_the_sdk but are not particularly helpful either, as they inherit buildroot's spiritual assumption that you only want to build programs in connection with the setup for building a complete system - you can specify to only build a particular program, but you are still kind of expected to plug your program into the overall system's build system in order to do so. So, no great answer, but between the first option of explicitly invoking the cross compiler and the second of merging your program into the system, you can at least get things accomplished.

I just got my Omega2+ yesterday. The Cloud Compile feature seems to still be broken? My job is stuck in the queued state. Can it be possible that this has been broken continuously for the last 5 months?

Thank you so much! Yes, I am.

That was it. Thanks.

I wrote my library on PHP: https://github.com/VBaczynski/phpi2c And the sensor reader: https://github.com/VBaczynski/bmp-sensor-reader It works much faster then the Python version. (I don't know why...)

Thanks much this has me a little more on track. I looked over the header files, and almost every one appears to already have guards in place. BTW, this is proving a good lesson in the concept for me For good measure, and after reading the articles, I also put #pragma once at the top of all header files just in case. Unfortunately no luck. Looks like my errors are coming from the C files and not the headers. For example: build/can-utils-master-edit/slcan_attach.o: In function main': slcan_attach.c:(.text.startup+0x1): multiple definition of main' build/can-utils-master-edit/bcmserver.o:bcmserver.c:(.text.startup+0x1): first defined here Is placing guards in C file ALSO advised?

@Lazar-Demin as always, thanks for the response! I literally keep this open waiting for developments as they occur I am assuming that this information will come, but you seemed to point out something I was worried about: I have a bunch of static and/or dynamic libraries I want to link with, but without control of a makefile, I can't ensure the resultant application is built/linked properly. This is a slight downside, but, I can just build something that requires static libs myself, at that point, as I'd have more capabilities myself then cloud compile would actually give me. To that end, I just realized that I could extend the docker container I made up for nodejs compiling to utilize the toolchain and create a arbitrary programs given a directory filled with makefiles/sources/static libs. Nominally, I could mount a directory of a project via -v flag to draw in any git repo for building in my toolchain container. I could then have a build hook/script within the container or in the git repo that, post-build step, POSTs the results to onion cloud for loading and installation to the omega. This would entail that I also, along with mounting the project directory, perhaps mount the credentials directory for the specific API key I want to post to. . . Love it! Now that onion cloud/ubus/api integration is up, I feel the community can move at a much faster pace. I feel, though, that perhaps you should invite and open up your design meetings to members of the community (as much as you can without sacrificing your competitive edge) so that community advocates can do this sort of documentation and whiteboarding for you I mean, I'm happy to spitball all my good ideas and all, but I feel you all should get to your core business and allow critical functions to be taken over by your dedicated and fanatical community. Keep up the good work!